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REMARKS 

Favorable consideration and allowance are respectfully requested for the claims in view 
of the foregoing amendments and the following remarks. Claims 23 and 32 are amended to 
provide proper syntax by inserting the word "a" in claim 23 and deleting the word "a" in claim 
32. New claim 56 depends from claim 48 and includes the limitations of claims 24, 25, 26 and 
27. 



35 U.S.C. §103(a) Rejections 

The rejection of claims 1, 3-27, 36, 38, 40, 46-48 and 51-55 under 35 U.S.C. § 103(a) 
over Samo Zorc (US Publication No. 2003/0167444 Al) in view of Michael Koch {Leverage 
legacy systems with a blend of XML, XSL, and Java®, October 6, 2000, JavaWorld.com) Ray Y. 
Lai (US Publication No. 2005/0044197 Al) and Applicant's admitted prior art (APA) is 
respectfully traversed. 

Claim 1 is directed to methods including automatically generating source code in a 
program language, compiling the source code and using the source code to transform messages 
between a program language and an online transaction processing (OLTP) language. The step of 
automatically generating the source code involves receiving a markup language document 
describing each type of message in the OLTP language. Automatically generating the source code also 
involves receiving a template for code in a program language, where the template describes the data 
format for the message in a target program language. When compiled and executed, this 
automatically-generated source code will transform messages directly between the target 
program language data format and the OLTP language message format. 

Thus, the claimed method involves a first step of automatically generating source code in 
a program language based on (i) a markup language document describing each type of message in an 
OLTP language and (ii) a template for code in a target program language. A second step involves 
using this automatically generated source code to transform a message between the target program 
language format and the OLTP language message foimat. The italicized language here points out 
that the transformation performed by the source code is transformation between languages that were 
used in generating that very source code. 
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None of the cited references discuss automatically generating source code from both a 
template and a markup language document, as contemplated in the claims. Further, none of the 
references discuss compiling and executing this automatically generated source code to then 
transform a message directly between a target program language format and an OLTP language 
message format. 

Zorc teaches a method using source code to translate between XML and another 
language, for instance, Java, see paragraph [0023]. As shown in Figure 1, the particular 
implementation involves translating a message from a first language into a common XML form, 
communicating that XML form of the message and then translating the received XML message 
into another format. Zorc is directed to methods that facilitate communication between different 
parties using standard XML fomiatted messages as an intennecHate. 

Zorc provides no teaching to automatically translate into a format specified by another 
program as is contemplated in the present claims. Further, Zorc does not teach or even 
contemplate a translation directly between an OLTP language format and a target program 
language. Nor does Zorc contemplate such a translation based on code that is automatically 
generated from an input of (i) a markup language document describing each type of message in the 
OLTP language and (ii) a template for code in the target program language. 

Zorc's suggestion to communicate using XML formatted messages as an intermediate, 
actually teaches away from the claims of the present application, which require automatic 
translation directly between message formats. The claimed invention does not contemplate 
translation of XML message, rather, a markup language document (describing each type of message 
in an OLTP language) and a template (for code in a program language) are used to generate source 
code to effect a translation directly between OLPT and a program language format. The claim 
language excludes the use of an intermediate, such as Zorc's XML. 

Further, Zorc relies on manually created code toactually handles the translation to and 
from XML. This code is not, as is presently claimed, code that is automatically generated based 
on the markup language document and template described above. 

Similarly, the Koch reference is directed to translating messages into an XML format, not 
directly between a program language format and an OLTP format. Koch begins with the following 
description (emphasis added): 
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No matter which way you try it, interfacing a mainframe from an application server 
or servlet is never fun. Among other hurdles to overcome, the mainframe could 
exist on a different platfonn or use a different character set. Think you can simply 
access the data directly and rebuild your business logic? Perhaps, if your database is 
not hierarchical and you enjoy reinventing the wheel. However, a few tricks 
using XML, XSL, and Java can make it easier than you tiiink. 

XML describes the structure of the data you are sending. Add XSL to 

complete some simple transformations. Use Java to encapsulate it with a few 
simple classes. You will then leverage a host of legacy system transactions 
written decades ago and format them into an XML document. Once your 
data is in an XML format, manipulating it becomes a much less daunting task, 
and development becomes easier. In addition, the solution you employ is realtime, 
which circumvents the frustrations and problems that arise from working with an 
extract file or batch interface. 

Indeed, careful examination of Koch shows that Koch teaches the use of XSL as a tool to 
further alter the format of an XML document. At the bottom of page 2, Koch teaches that: 

You will use XSL to format an incoming document structure to the name/value- 
pair structure described above, which the Java code processes into the COBOL 
structure. XSL will also format the data returned from the legacy system — once 
the Java code tiansforms it back into XML ~ into a usable structure for the 
function or application using this API. 

Koch provides no indication that XSL might be used as a template to generate code that 
performs message conversion. Instead, like Zoic. Koch i-elies on manually created coded. Koch 
does not contemplate, as is presently claimed, code that is automatically generated based on the 
markup language document and template described above. In particular, Koch describes translating a 
message from the message format of a COBOL program into an XML format. Koch then suggests 
using individually creating XSL stylesheets to fiirther translate the XML into a format useftil for some 
other system, for example, by selecting particular fields in the XML format. This is completely 
different form the claimed invention. 

Even assuming that one were to attempt a method of using XML as an intermediate, any such 
method would be significantly different from the present claims which require the system to 
"transform the payload message directly between the target program language data format and the 
online transaction processing (OLTP) language message format." Any such direct 
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transformation cannot be achieved using the use of the XML-based systems described in Koch 
or, for that matter, the XML intermediates of Zorc. 

The communication methods of Zorc and Koch are disadvantageous due to the high costs 
associated with handling XML communications. Because XML message transmissions tend to 
be resource intensive, related communications systems for handling their transmission are costly. 
Where a system is required to handle a high message volume with limited resource allocation, 
and perform these functions at minimal cost, XML based transmissions are unsuitable. 

The Office Action cites paragraphs [0038], [0039] of the Lai publication as relevant to 
the claimed method involving use of a markup language document (describing each type of message 
in an OLTP language) and a template (for code in a program language) to generate source code to 
effect a translation directly between OLPT and a program language format. Hoever, these 
paragraphs do not describe such a method. Instead, paragraphs [0038] and [0039] indicate that 
JAXB is "Java Architecture for XML Binding." More particularly, Lai teaches that JAXB is 
useful to translate XML elements into Java data objects. This is not the same as the source code 
creation step contemplated in the present claims. First, in the claims the source code creation is 
automatic. In contrast, Lai teaches manual creation of source code to handle the conversion of 
XML to Java data objects by programmers using the utility xjc (see the first line of [0039]). The 
Office Action appears to acknowledge Lai's requirement for manual programming, see page 7 of 
the Office Action and the discussion below. Further, translating XML elements into Java data 
objects as taught by Lai, is significantly different from the translation contemplated in the 
claimed invention, which transforms a message directly between the target program language 
format and the OLTP language message format. 

Applicant's also wish to point out that the Office Action's reliance on "applicant's 
admitted prior art" is improper. Applicants do not agree that any admission to prior art was 
made or that the material referred to as "applicant's admitted prior art" is prior art to the present 
application. In particular, the Office Action alleges "applicant's admitted prior art" discloses 
"transformation of a payload message directly between the target program language data format 
and an OLTP language message format." 

The Office Action states that "Zorc, Koch, and Lai do not explicitly disclose" 
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using the compiled automatically-generated source code to transform the 
payload message directly between the target program language data format and 
the online transaction processing (OLTP) language message format. 

The Office Action then points to the specification beginning with paragraph [0005] as making up 

for the deficiencies of these references. However, this section of the specification refers only to 

manually coded source code designed to translate a message from an OLTP format to the format 

of a particular program or vice versa. This section does not suggest that such source code may 

be generated automatically. In contrast, this language makes clear that automatically generating 

such source code is not known. 

In sum, none of the teachings relied on in the Office Action disclose or suggest an 
automatic source code generation, as is required in the claims. None of the reference teach that 
by using (i) a markup language document describing each type of message in an OLTP language and 
(ii) a template for code in a target program language one might be able to automatically develop 
source code for transforming directly between a target program language format and an OLTP 
language message format. 

Further, none of the cited references (Zorc, Koch and Lai) teach a transformation directly 
between a target program language format and an OLTP language message format as 
contemplated in the claimed invention. Instead, Zorc and Koch teach translating messages from a 
program language into XML. Lai teaches translating XML elements into Java data objects. 

Even assuming that a skilled artisan, were, for some reason to attempt to combine the 
teachings of Zorc, Koch and Lai, the result would be a system where a program language is 
translated into XML and the resulting XML is then translated into Java data objects. Such a 
system is nothing like the claimed method, where source code is automatically generated based 
upon input relating to a target program language and an OLTP language and the source code is 
then used to translate between a program language data format and an OLTP language message 
format. Not only do these references not teach the required translation, or the automatic 
generation of the source code, the references are silent on the concept of using both (i) a markup 
language document describing each type of message in an OLTP language and (ii) a template for code 
in a target program language to automatically develop the source code. 

The alleged "admitted prior art" does not make up for the failure of these references to 
teach the limitations of the claims. At best, this section of the application states that a 
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programmer could manually write code to transform messages between an OLTP language and a 
target program language. However, there is no suggestion that this manual coding could be automated 
or that suitable source code could be automatically generated from a markup language document and a 
template for code in a target program language. 

Accordingly, the proposed combination of references does not teach or fairly suggest 
each and every limitation of the claimed invention and the obviousness rejection cannot be 
properly upheld. 

Each of the claims dependent from the independent claims is allowable for at least these 
same reasons. Certain of these dependent claims are discussed further below. 

For claims 4 and 5, the Office Action's equating Koch's "Fig. 1 - Legacy transaction 
framework" is misplaced. It is not clear from the Office Action where exactly Figure 1 in Koch 
is considered to appear. Further, Koch deals with translation of messages from a program 
language into XML. This differs from the claimed system where one automatically generates code 
to handle a translation directly between the a program language and an OLTP language. Indeed, 
Koch teaches that this cannot readily be done, stating: "Think you can simply access the data directly 
and rebuild your business logic? Perhaps ... if you enjoy reinventing the wheel." 

Even assuming that one were to realize a method of using XML as an intermediate, any such 
method would be significantly different from the present claims which require the system to 
"transform the payload message directly between the target program language data format and the 
online transaction processing (OLTP) language message format." Any such direct 
transformation cannot be achieved using the the XML-based systems described in Koch or, for 
that matter, Zorc. 

Claims 7 and 8 address using a stylesheet and stylesheet parser. As indicated above, 
Koch makes an entirely different use of a stylesheet and stylesheet parser which is not directed to 
generating code that is used for a subsequent transformation between the target program 
language data format and the OLTP language message format (as is presently claimed) - see the 
discussion of XSL above. 

Finally, Applicant's wish to point out that contrary to U.S. Patent Office rules and 
regulations, the record does not establish the date on which the Koch reference was made 
publicly available. 
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Section 2128 of the MPEP states that 

Prior art disclosures on the Internet or on an on-line database are considered to be 
publicly available as of the date the item was publicly posted. *> Absent evidence 
of the date that the disclosure was publicly posted, if< the publication >itself< 
does not include a publication date (or retrieval date), it cannot be relied upon as 
prior art under 35 U.S.C. 1 02(a) or (b)*>. However<, it may be relied upon to 
provide evidence regarding the state of the art. Examiners may ask the Scientific 
and Technical Information Center to find the earliest date of publication >or 
posting<. See MPEP § 901.06(a) . paragraph IV. G. 

The Koch document was apparently retrieved from the Internet on September 13, 2007, as 
evidenced by the data stamp appearing at the bottom of the reference pages. This date is not 
useful to establish the reference predated the present application. The Office Action presumes 
that the date of October 6, 2000 appearing aside the author's name is the actual posting date of 
the article. However, there is actually no way to discern whether this is the date that the article 
was actually made publicly available on the Internet. It is just as likely that October 6, 2000 is 
the actual date the author completed his article, or perhaps the date that the article was formally 
submitted to the JavaWorid publication. However, the line "By Michael Koch, JavaWorld.com, 
10/06/00" does not, by itself, confirm that the reference was actually publicly available in 
October 2000. Similarly, the record does not establish that the version of the reference that was 
retrieved on September 13, 2007 is identical to any version that was available prior to September 
13, 2007. 

Accordingly, the standards for establishing the date of the reference have not been met 
and the reference cannot be properly relied on as prior art. 

Reconsideration and withdrawal of this rejection are therefore respectfully requested. 



The rejection of claims 28, 30-35, 42, 44 and 49-50 under 35 U.S.C. § 103(a) over Zorc, 
Koch and APA is respectfully traversed. 

Despite the similarities shared between the language of independent claim 1 and 
independent claims 28 and 32, the Office Action did not rely on the Lai reference for this 
rejection. 
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Each of Zorc and Koch and APA are discussed in detail above. The resulting 
combination of prior art references teach translating messages into an XML format. In the case 
of Koch, a subsequent further modification using XSL may be performed, however there is no 
directed transformation between a target program language data format and an OLTP language 
data format. The use of XML as an intermediate excludes the teachings of these references from 
being directly relevant to the claimed invention. 

Moreover, there is no teaching of a module capable configured to receive a markup 
language document and a template for code in a program language, the template describing a 
message data fonnat in a target program language, where that module is configured to 
automatically generate the transformation source code in the program language. As discussed 
above, Koch's use of XSL to further modify XML in a downstream (multistep) process is 
completely different from the invention of the claims. 

Still further, there is no description in either the prior art references or the APA to 
provide a system capable of doing this automatically. 

Each of the claims dependent from the independent claims is allowable for at least the 
same reasons. 

Accordingly, the proposed combination of references does not teach or fairly suggest 
each and every limitation of the claimed invention and the obviousness rejection cannot be 
properly upheld. Reconsideration and withdrawal of this rejection is respectfully requested. 

CONCLUSION 

In view of the foregoing, the application is respectfully submitted to be in condition for 
allowance, and prompt favorable action thereon is earnestly solicited. 

If there are any questions regarding this response or the application in general, a 
telephone call to the undersigned would be appreciated since this should expedite the prosecution 
of the application for all concerned. 
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The fee representing payment for an extension of time is being simultaneously submitted 
herewith via the Electronic Filing System (EFS). In the event that any further fees are due, or 
refunds allowed, please apply any charges or credits to deposit account 50-321 1 
(21204.0121US). 

Respectfully submitted. 



Date: February 4. 2010 /Christopher T. McWhinnev/ 

Christopher T. McWhinney 
Reg. No. 42,875 
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Sullivan & Worcester LLP 
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Facsimile: (202) 293-2275 
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